1. Technical Field
The present invention relates in general to the field of computers, and in particular to computers running JAVA™ files. Still more particularly, the present invention relates to a method and system for a novel use of a JAVA™ Custom ClassLoader to dynamically build and maintain a list of JAVA™ Class Files and resources that are used by an application running in a Point Of Sale (POS) device.
2. Description of the Related Art
In a retail environment, Point Of Sale (POS) terminals are used to 1) check out a customer while 2) keeping a running stock inventory based on what items are sold/returned. POS terminals communicate with a controller, which provides files and data to the POS terminal on an as-needed basis.
POS terminals often run using software written in an Object Oriented Programming (OOP) language. OOP utilizes classes, which are data types that allow the creation of objects. A class provides the definition for a collection of objects by describing methods (operations) and specifying the attributes (data) that may be manipulated by those methods. Thus, by defining a class, individual objects (also called “instances”) can be created and executed.
A popular OOP language is JAVA™, which is a robust, portable OOP language developed by Sun Microsystems, Inc. (Note that JAVA™ and all JAVA-based marks are a trademark or registered trademark of Sun Microsystems, Inc, in the United States and other countries.) JAVA™ attains its portability through the use of a specially-designed Virtual Machine (“VM”). This virtual machine is also referred to as a “JAVA™ Virtual Machine”, or “JVM”. The virtual machine isolates the details of the underlying hardware from the compiler used to compile the JAVA™ programming instructions. The compiled code, referred to as JAVA™ “byte code”, then runs on top of a JVM, where the JVM is tailored to a specific operating environment.
In a JAVA™ environment, if a POS terminal needs a particular JAVA™ class (data type that allows the creation of an object in JAVA™) for a particular operation (e.g., to exchange a piece of merchandise), then the POS terminal sends a request for that JAVA™ class to the controller, which responds by sending the POS terminal the requested JAVA™ class.
However, if communication should be disrupted between the POS terminal and the controller, then the application running on the POS terminal will crash, due to the unavailability of the needed JAVA™ class.
To address this problem, the 4690 Operating System (OS) Version 3 Release 3 from International Business Machines (IBM™), whose specification is herein incorporated by reference in its entirety, has a feature known as JAVA™ Terminal Offline Function (JavaTOF). (Note that IBM™ is a trademark of International Business Machines Corporation in the United States, other countries, or both.) JavaTOF allows a controller user to create a first zip file containing all JAVA™ classes that may be required by an application, and a second zip file that contains all resource files that may be required by the application. The zip files are then loaded onto a RAM disk on the POS terminal, which allows the application to access the required JAVA™ classes and resource files from the local terminal RAM disk. Thus, if a terminal loses its connection with the controller, the application can continue to operate in Terminal Offline Function Mode.
While JavaTOF is a very useful improvement, it has certain limitations. First, the zip files for the JAVA™ classes and resources must be manually configured. A programmer must decide which files are to be sent to the POS terminal, and then zip and send them from the controller to the POS terminal. This step is error-prone and time consuming. Second, because of their sizes, sending a complete set of JAVA™ classes and resources is a waste of communication bandwidth between the controller and the POS terminal, and can be a waste of memory space in the POS terminal. Third, because JavaTOF uses a static list of resources, if an unexpected dependency should occur in a JAVA™ class, execution of the JAVA™ class will fail if the necessary class or resource is unavailable. Fourth, if all of the JAVA™ classes and resources are not tested before delivery to the POS terminal, then their static nature prevents the POS terminal from having a corrected newer version of the requisite JAVA™ class and/or resource. Fifth, JavaTOF cannot support 3rd party applications that are dynamically “plugged-in” at runtime.
What is needed, therefore, is a method and system that allows a customized JAVA™ ClassLoader to dynamically build and maintain a list of JAVA™ Class Files and resources that are used by the POS terminal. Preferably, if communication is broken between the controller and the POS terminal, other POS devices can dynamically collaborate to supply the first POS device with the requisite JAVA™ classes and resources.